home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19990725-20000114
/
000428_news@columbia.edu _Sat Jan 8 16:23:51 2000.msg
< prev
next >
Wrap
Internet Message Format
|
2000-01-13
|
7KB
Return-Path: <news@columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id QAA20340
for <kermit.misc@watsun.cc.columbia.edu>; Sat, 8 Jan 2000 16:23:50 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id PAA06440
for kermit.misc@watsun.cc.columbia.edu; Sat, 8 Jan 2000 15:56:10 -0500 (EST)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Subject: Case Study #2: Kerbang Scripts
Date: 8 Jan 2000 20:56:09 GMT
Organization: Columbia University
Message-ID: <858899$695$1@newsmaster.cc.columbia.edu>
To: kermit.misc@columbia.edu
Today's topic is Kerbang scripts. This discussion is oriented mainly to
UNIX users, and was alluded to in yesterday's posting. Here is a fuller
explanation.
A nice feature of UNIX is the ability to run shell scripts just if they
were compiled binary programs or built-in shell commands, just by typing
their names and, optionally, including command-line arguments. For
example, suppose that as a common task you need to move some files to the
/usr/local/etc/ directory; your shell script might look like this:
for i in $*; do
echo $i =\> /usr/local/etc/$i
mv $i /usr/local/etc/$i
done
If you saved this script as a file called (say) "move" in a directory
that is in your PATH, and gave it execute permission:
chmod +x move
then you could type commands such as:
move foo.bar
move *.log
move file1 file2 file3 ...
at the shell prompt, and the script would move all the files whose names
were given on the command line (wildcards are automatically expanded by
the shell into a list of matching files).
The shell gives us various mechanisms to refer to command-line arguments
within a script: $* is replaced by all the arguments, $# is replaced by
the number of arguments, $1 is replaced by the first argument, $2 by the
second, and so forth. There is also a "shift" command that can be used
(e.g.) to access arguments beyond $9.
Now suppose you need some features in your script that were only available
in a particular shell, which might not be the default shell. Most UNIXes
let you include a "special comment" as the first line of a script, which
starts with the characters "#!" and then gives the full pathname of the
shell which is to execute the script, e.g.:
#!/bin/ksh
This is sometimes called the "shebang" line ("she" for shell and "bang" is
Unix slang for the exclamation mark). It is not indented; the shebang
line must be on the left margin (indentation is used here to set examples
off from text).
Happily, this convention can be applied to any program at all, Perl for
example, so Perl scripts generally have execute permission and a first
line like:
#!/usr/local/bin/perl
This lets us run Perl scripts just as if they were shell scripts or, for
that matter, precompiled programs or built-in shell commands.
C-Kermit 7.0 extends this idea to Kermit scripts. In this case the
shebang-line contains the full path of the Kermit program, followed by
a space and then a plus (+) sign:
#!/usr/local/bin/kermit +
and the last line in the script is usually EXIT, to make C-Kermit exit
when the script is finished (the plus sign means "treat command-line
arguments as arguments for the script, not arguments for Kermit"). We
call these Kerbang scripts.
Here is a simple Kerbang script that prints its arguments:
#/usr/local/bin/kermit +
echo Hello from \%0
for \%i 0 \v(argc)-1 1 {
echo \%i. "\&_[\%i]"
}
exit 0
In Kermit the number of command line arguments (including the name of
the script itself) is in the \v(argc) variable. The "argument vector"
is a special array, \&_[], having \v(argc) elements, 0 through \v(argc)-1.
The loop above prints each argument.
Save this file as (say) "showargs", then give it execute permission and
run it:
$ chmod +x showargs
$ ./showargs one "this is two" three
The script displays its arguments:
Hello from /usr/olga/showargs
0. "/usr/olga/showargs"
1. "one"
2. "this is two"
3. "three"
Notice that shell quoting rules, not Kermit ones, apply to the command-
line arguments since you are, indeed, typing this command to the shell,
which parses the arguments and passes them along to Kermit.
Kermit scripts give you the same ways to access the command line arguments
as shell scripts do, but with different syntax:
Shell Kermit Description
$# \v(argc)-1 The number of command-line arguments
$* \%* A string containing all the command-line arguments
$0 \%0 The name of the script
$1 \%1 The first command-line argument
$2 \%2 The second command-line argument
$3 \%3 The third command-line argument
... ... ...
$9 \%9 The ninth command-line argument
shift shift Shift the command-line arguments
(???) \&_[] The entire command-line argument vector,
even if there are more than 10 elements.
$? \v(status) Completion status of previous command.
Of course you can put any commands at all into a Kerbang script. It can
read and write files, make connections, transfer files, anything that
Kermit can do -- because it *is* Kermit. And of course, Kerbang scripts
can also be executed from the Kermit prompt (or from another script) with
a TAKE command; the Kerbang line is ignored since it starts with "#",
which is a comment introducer to Kermit just as it is to the UNIX shell.
In VMS and other non-UNIX platforms, the Kerbang line has no effect.
An especially handy use for Kerbang scripts is to have the C-Kermit
initialization file itself be one. Since the standard initialization file
is rather long and time-consuming to execute (setting up your services
directory, etc), it is often overkill if you want to start Kermit just to
transfer a file. Of course there is a command-line switche to suppress
initialization-file execution but another approach is to "run" the
initialization file when you want its features (notably the services
directory), and run C-Kermit directly when you don't. A setup like this
requires that (a) the C-Kermit initialization file is configured as a
Kerbang script (has #!/path../kermit as first line), has execute
permission, and is in your PATH; and (b) that you don't have a .kermrc
file in your login directory.
Almost all of this is new to C-Kermit 7.0, and there are lots more
wrinkles to it. Of course Kerbang scripts can be used in VMS and other
non-Unix platforms, but the methods for invoking them are different. For
details, see the ckermit2.txt file, Sections 7.5 and 7.19. To see lots of
sample Kerbang scripts, many of them quite practical, visit the C-Kermit
Script Library at:
http://www.columbia.edu/kermit/ckscripts.html
- Frank